Skip to content

Environment-specific outdated_mode? #378

Open
Open
Environment-specific outdated_mode?#378
Labels
enhancementNew feature or request

Description

@jsw800
jsw800
opened on Mar 17, 2025

Details

On my team, we would like to enforce that our dev environment is always up to date with main, but other environments such as staging and production don't have that requirement, as sometimes we need to branch deploy a hotfix branch there which will most definitely be out of date with main, so the outdated enforcement becomes a hindrance.

For a while we had just disabled outdated checks for all environments, but it's caused the occasional confusion when people accidentally deploy outdated changes to dev where that's unexpected 😅 so we're looking to go back to properly enforcing those rules.

Since the environment/command parsing all happens internal to the branch deploy workflow, I can't figure out a way to make the outdated_mode environment specific. For the time being I've implemented a bit of a workaround where I have my own step after the branch deploy step that checks the environment and is_outdated outputs and responds accordingly, but it's a bit hacky, and has the side-effect of showing the "deployment triggered" comment before then displaying my own custom outdated comment, which certainly isn't ideal 😅

I'm wondering if this is something that would be feasible for the workflow to support internally?

Activity

  1. jsw800
    added
    questionFurther information is requested or the issue is a question
    on Mar 17, 2025
  2. GrantBirki
    added
    enhancementNew feature or request
    and removed
    questionFurther information is requested or the issue is a question
    on Mar 17, 2025

  3. GrantBirki commented on Mar 17, 2025

    @GrantBirki
    GrantBirki
    on Mar 17, 2025
    Contributor

    @jsw800 I think that sounds like a great idea and I totally understand your use case.

    How would something like this sound:

    If the outdated_mode input is set to a single option such as strict then that option is applied to all environments. If the outdated_mode input is set to an comma separated list of options:environments, use that option for the given environment. For example: outdated_mode: production:pr_base,dev:strict,staging:pr_base.

    Now of course, if you had these new mappings for outdated_mode we would also need them for the update_branch input option as well to control how we handle "out of date" branches.

    Full example:

    - name: branch-deploy
  id: branch-deploy
  uses: github/branch-deploy@vX.X.X
  with:
    trigger: ".deploy"
    outdated_mode: production:pr_base,dev:strict,staging:pr_base # this here shows "dev" is the most strict for determining "out of date" branch logic
    update_branch: production:disabled,dev:warn,staging:disabled # this here shows that staging & production will let you deploy "out of date" branches, but the dev env will reject those deployment and warn you that your branch is "out of date"

    Additionally, I think it would make sense to fall back to the default input option if a user simply leaves out a mapping for how an environment should be handled. For example, strict is the default for outdated_mode. If a new env gets used called sandbox, and it doesn't have a mapping, then it should fall back to strict rather than failing the Action due to a missing definition.

  4. jsw800 commented on Mar 17, 2025

    @jsw800
    jsw800
    on Mar 17, 2025
    Author

    @GrantBirki That'd be awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions