Automation and enhancement of the dev workflow about iscsc.fr HOT 30 OPEN

Just wanted to tell that I will now work on the Deployment of the website point
I'll add a Docker deployment for the app
PR incoming

from iscsc.fr.

I think @amtoine's script is quite convenient for the task! We just need to share the protected 7z files when we want.
An easy way can be to send it on the discord server! Let's try like that!

from iscsc.fr.

It's the idea yes! I'll create two tables users-dev and articles-dev alongside in the database

Perfect!

Mmm that sounds very good! Do you want to automate this or do it manualy?

No absolutely not but it has to be made at each release

from iscsc.fr.

I don't really like the idea of pushing the .env even encrypted 🤔
The repo will be dirty and I don't think it's a good solution
We could otherwise upload it to a cloud automatically or send it by mail
Or develop a bot that send it on discord

from iscsc.fr.

Again the issue is not for you but more for me when I want to share

i know, i wrote it for you 😋
i do not share any .env file in this project myself 🤔

But thanks to your script it should be easier
Could you open a PR and add it? You can create a script folder in the root directory and put it here

i can 👍

from iscsc.fr.

i dunno, i wouldn't use such features myself to share secrets, but maybe these are great directions, there's no big harm in trying yum

Because you as yourself don't need to share and synchronize secrets among a team, that's a different problem I think!

from iscsc.fr.

definitely something to address!
100% agreed with what is said above 👌

another question that might fit in this issue: how and when do we deploy the blog on https://iscsc.fr/? 😋

from iscsc.fr.

another question that might fit in this issue: how and when do we deploy the blog on https://iscsc.fr/? yum

I was thinking about opening another issue for this one, but go ahead if you want 😉

from iscsc.fr.

Alright you have a good point here @atxr
I can't wait to see your PR opened!

About the "messing with the DB" thing wouldn't it be possible to, during development process, redirect the data towards a different table of the DB to let the developers test everything without messing up with the running website?

Linked to that point I have another request:
A tag of the version commit on the main branch. Now that v0.0.1 is released we should add a tag (I mean a git tag) on a commit of the main branch. But tagging a PR commit is not clean neither tagging an empty.
I then propose a workflow I witnessed during my summer internship: after the last PR/bug fix we stop every merging on main and push a single commit for example: "Release v0.0.1" containing an update of a .json file for example:

{"version":"0.0.1"}

I find this quite clean and explicit! And just before, after or even in this commit we could also add the needed update to redirect the connection to a "Running" table of the DB (in contrast with a "Dev" during dev time).
Let me know if I'm not clear or if you want me to open another Issue for this.

from iscsc.fr.

@ctmbl

this is a "bump to version xxx" commit / tag right? 😋

from iscsc.fr.

Absolutely!

from iscsc.fr.

that's cool 👍

from iscsc.fr.

About the "messing with the DB" thing wouldn't it be possible to, during development process, redirect the data towards a different table of the DB to let the developers test everything without messing up with the running website?

It's the idea yes! I'll create two tables users-dev and articles-dev alongside in the database

Linked to that point I have another request: A tag of the version commit on the main branch. Now that v0.0.1 is released we should add a tag (I mean a git tag) on a commit of the main branch. But tagging a PR commit is not clean neither tagging an empty. I then propose a workflow I witnessed during my summer internship: after the last PR/bug fix we stop every merging on main and push a single commit for example: "Release v0.0.1" containing an update of a .json file for example:

{"version":"0.0.1"}

I find this quite clean and explicit! And just before, after or even in this commit we could also add the needed update to redirect the connection to a "Running" table of the DB (in contrast with a "Dev" during dev time). Let me know if I'm not clear or if you want me to open another Issue for this.

Mmm that sounds very good! Do you want to automate this or do it manualy?

from iscsc.fr.

So we made a new step to solve this issue! The last thing remaining:

• Find a better way to share .env files

from iscsc.fr.

So we made a new step to solve this issue!

where has that step been made? 😋

The last thing remaining:

• Find a better way to share .env files

using public pgp key sharing does not fit the workflow? 🤔

it is not hard as we've been doing it together @atxr, but requires a tiny bit of knowledge, so finding a more user friendly way could be great

from iscsc.fr.

The step was the production mode PR 😁

And it's actually easy for you but not for me, I have to generate several .env files for each of you manually each time I want to share it.
I was thinking of an automated sharing in a secure way of the env file

from iscsc.fr.

The step was the production mode PR grin

got it 👍

And it's actually easy for you but not for me, I have to generate several .env files for each of you manually each time I want to share it. I was thinking of an automated sharing in a secure way of the env file

well, you only need the public usernames and the path to the file to be shared, then all the sharing process can be automated with gpg in a shell script:grey_exclamation: :yum:
you can even share a ziped archive with all the files directly to everyone

something like

#!/usr/bin/env bash

file="/path/to/file"
users=(
    foo
    bar
    baz
)

for user in "${users[@]}";
do
    gpg --recipient "$user" --encrypt --armor --output "$file.$user.asc" "$file"
done

7zz all.7z ...
# or
zip ... -d all.zip

and then all.zip or all.7z can be distributed to foo, bar and baz at once
then you just add the users to your keyring once and run the script each time the file change 😋

from iscsc.fr.

In fact we could do this, but why bothering with bash scripts if we simply can find a way to automate the whole process?
Not saying that we can find something easier that what you're proposing!

from iscsc.fr.

In fact we could do this, but why bothering with bash scripts if we simply can find a way to automate the whole process? Not saying that we can find something easier that what you're proposing!

yup, that's the simplest i can think of right now 👍
it's with our pgp keys, so we control exactly who can access the credentials

from iscsc.fr.

Maybe we could use this script and git add the zip file of to the repo 🤔
The other solution I saw was to create a vault on a server with a shared pgp key or a already existing service
Be can basically grab the .env file here and we could create a push action that upload the .env on the vault 🤔
Sounds complex because it's like re-implementing github 🤔

from iscsc.fr.

Maybe we could use this script and git add the zip file of to the repo thinking

yup that's an idea 👍

maybe in a secret/ or .env/ directory to isolate that part of the workflow from the root 👌

from iscsc.fr.

@atxr
as you wish

all of this sounds very complex and quite overkill compared to a regular bash script and pgp keys sharing 🤔
i'm quite comfortable with pgp myself so not a big deal for me 😋

if you want to search a more newbie-friendly solution, go ahead 👌

from iscsc.fr.

Again the issue is not for you but more for me when I want to share
But thanks to your script it should be easier
Could you open a PR and add it? You can create a script folder in the root directory and put it here

from iscsc.fr.

Even if I like @amtoine 's script I don't feel comfortable with pushing the archive on the repo too... I can't find a way to exploit this at the moment but I'm sure one could find it... We should use pgp/gpg keys but we shouldn't push the archive on GitHub 😕

I found this post that asks the same question. And these repo that adresses that problem:

• https://github.com/envault/envault
• https://github.com/codeshifu/sync-dotenv-slack
• https://github.com/occson

I personally can't look into it but maybe someone could?

from iscsc.fr.

mm 🤔

i was not proposing to push the secrets to GitHub either 👍

but "exploiting this" as you say means exploiting pgp and modern cryptographic protocols right?
that looks quite unlikely and safe to me 🤔

'cause then we have the same problem sharing the .env.asc gpg-encrypted files as we've done 'till now on discord 😕

i'm not very familiar with these cs concerns, i might be missing things 😋
but that looks quite safe to me to share the .asc gpg-encrypted files 😮

from iscsc.fr.

I found this post that asks the same question. And these repo that adresses that problem:

• https://github.com/envault/envault
• https://github.com/codeshifu/sync-dotenv-slack
• https://github.com/occson

I personally can't look into it but maybe someone could?

i dunno, i wouldn't use such features myself to share secrets, but maybe these are great directions, there's no big harm in trying 😋

from iscsc.fr.

@atxr I just checked Sharing of .env in a secure way to authorized developers 🚀

from iscsc.fr.

@atxr I just checked Sharing of .env in a secure way to authorized developers rocket

is "Sharing of .env in a secure way to authorized developers" supposed to be a link to some external resource? 😋

from iscsc.fr.

Still one more point to address to fix this issue! 🥳

from iscsc.fr.

we're almost there 🥲

from iscsc.fr.