search

liquibase / liquibase-docs

7 stars 16 forks source link

DAT-12359 move redirect publishing to docs repo #170

Closed ap-liquibase closed 1 year ago

ap-liquibase commented 1 year ago

I don't think it actually is missing the piece that would sync the content in the bucket from staging to prod. upon reflection I seem to remember that Doc team wants to push content directly from Flare to Prod bucket. My plan was to talk to doc team to confirm this. If I'm wrong then I'll add the sync workflow.

jnewton03 commented 1 year ago

I don't think it actually is missing the piece that would sync the content in the bucket from staging to prod. upon reflection I seem to remember that Doc team wants to push content directly from Flare to Prod bucket. My plan was to talk to doc team to confirm this. If I'm wrong then I'll add the sync workflow.

For now we should replicate the current workflow. If they decide to use flare with different publishing destinations then we can update it then.

ap-liquibase commented 1 year ago

Apparently publishing publishing directly to prod is the current liquibase doc workflow (according to Amber). The legacy Jenkins step is only done for Enterprise/DMC docs.

ap-liquibase commented 1 year ago

Hi @jnewton03 Demonstrated the staging workflow to Catherine and team this morning. After discussions it was decided to have production workflow ("send-redirects-to-production.yml") run only when PR is merged, usually with approval from Catherine. Please take a look at send-redirects-to-production.yml to see if it looks good/secure to you. (Also, the consensus was to publish non-redirect content from Flare directly to Prod bucket. Thus there is no need to have a bucket sync step anymore, like in Jenkins)

jnewton03 commented 1 year ago

@ap-liquibase if the trigger for deploying redirects to staging is a push to master/main and the trigger for redirects to prod is a PR merge, then anytime a PR is merged to master/main both jobs are going to run because a PR merge technically is a push to the destination branch as well, isn't it?

ap-liquibase commented 1 year ago

yes that is right, but should be harmless since there will be no changes to the resources in staging upon merge to prod (since they work from the same source of truth). But I get your point that this is not perfectly elegant. It may be better to make staging be a manually triggered workflow (i.e. workflow_dispatch). Processing ...

ap-liquibase commented 1 year ago

This commit prevents PR merges from triggering redirects to staging action

jnewton03 commented 1 year ago

This workflow seems odd with these triggers. Am I following correctly?

  1. Docs team adds redirect to redirect variable in main branch
  2. Docs team manually triggers deployment of new variables to staging from main branch
  3. Docs team opens PR from ??? to main branch with no changes?
  4. Docs team merges PR with no changes which triggers deployment to production?
ap-liquibase commented 1 year ago

@jnewton03 improved readme for clarity and added a branch input to staging workflow

jnewton03 commented 1 year ago

@ap-liquibase there's still a few comments above that have not been resolved. Additionally, I think this workflow is going to be error prone and require a lot of manual coordination by the Docs team. Consider the following:

  1. Doc writer A checks out FeatureA and makes redirect changes in their branch
  2. Doc writer B checks out FeatureB and makes redirect changes in their branch
  3. Doc writer A runs manual workflow to push redirects into staging to add redirect A
  4. Doc writer B runs manual workflow to push redirects into staging to add redirect B
  5. Since Doc writer B did not have Doc writer A's redirects in their branch ,Terraform may detect the drift and delete the redirects added by Doc Writer A